NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/636

Text File | 1996-08-06 | 6.2 KB | 208 lines

Path: chronicle.mti.sgi.com!austern
From: [e-mail] (James Kanze US/ESC 60/3/141 #40763)
Newsgroups: comp.std.c++
Subject: Re: Some ideas about C++ and a question
Date: 05 Mar 1996 09:47:05 PST
Organization: GABI Software, Sarl.
Approved: [e-mail]
Message-ID: <[e-mail]>
References: <4h9se5$[e-mail]>
NNTP-Posting-Host: isolde.mti.sgi.com
X-Original-Date: 05 Mar 1996 11:46:36 GMT
In-Reply-To: Valentin Bonnard's message of 04 Mar 1996 10:21:57 PST
Apparently-To: [e-mail]
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBVAwUBMTx+NEy4NqrwXLNJAQGBQgIAqBUpI9x3311/jCHRuZDwjTzPDaAT73lf
    mYkQSF3slRMQxlP5Ni6bdTo0QETWlz1XCbExsXxDjjZPmhhcryGxiA==
    =DY7c
Originator: [e-mail]

In article <4h9se5$[e-mail]> Valentin Bonnard <[e-mail]> writes:

|> I have 4 ideas about C++ and a question.

|> 1) String literals
|> ~~~~~~~~~~~~~~~~~~
|> String literals should be const char* instead of char* (if it is not
|> already the case).

I agree.  There was some discussion about this in the committee, but
as far as I know, there was never a real proposal.

|> 2) Placement operators
|> ~~~~~~~~~~~~~~~~~~~~~~
|> class Object {
|>         void    operator+ // or / or whatever
|>                          (Object& result, const Object& b) const;
|>         void    operator* (Object& result) const;
|>         Object  operator* (const Object& result) const; // old one
|> }

|> should be called respectively by:
|> a = b + c;

|> and a = *b;

|> and (old one) a*b;

|> This will solve the [well-known] problem of copying the result into a temporary.
|> The compatibility will be preserved since old syntax will be allowed to.

Presented like this, the idea sounds good.  Now try and define it
exactly.  In which cases is which operator used, and how?  What are
the exact semantics?  I think you'll find that it introduces an
enormous amount of additional confusion in an area which is already
not particularly clear.

|> 3) Use of explicit keyword
|> ~~~~~~~~~~~~~~~~~~~~~~~~~~
|> //========= Test.h =========
|> class Base {
|>     public:
|>         virtual void VirtualFunc ();
|> };

|> class Derived : public Base {
|>     public:
|>         void VirtualFunc () { }
|> };

|> //========= Caller.cp =========
|> #include <Test.h>
|> class Derived2 : public Derived {
|>     public:
|>         void VirtualFunc ();
|> };

|> //========= Foo.cp =========
|> #include <Test.h>

|> void    foo (explicit Derived* object)
|> {
|>     object.VirtualFunc (); // nop (compiler does not generate code for this)

|>     Derived* AnyDerivedObject = object; // ok
|> }

|> void    foo2 (Derived* object)
|> {
|>     object.VirtualFunc (); // object can be Derived2

|>     explicit Derived* RealDerivedObject = object; // error
|> }

|> The meaning of explicit could be: while a derived class ptr [resp. ref] can be
|> convert to a base class ptr [ref], it can't be converted to a base class
|> explicit ptr [ref].

|> So explicit would be a type qualifier; this usage is different with:

Seems confusing, and I really cannot see any use for it.  If the
derived class cannot be used where ever the base class is used, you
shouldn't be using (public) derivation.

|> > Rich Hickey
|> > [e-mail]

|> > I propose that the explicit keyword be allowed as a qualifier of a class
|> > definition, such qualification taking the form of:

|> > explicit class X{
|> >   //the definition of X
|> >   };

|> Here, X cannot be derived but my Derived can be so I think my idea is better
|> (please fell free comment/criticise this assertion).


|> 4) Conversion of Type** to const Type**
|> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

|> It's ok, this is an error; but why cannot Type** be converted to const Type*
|> const* ?

|> void    foo ()
|> {
|>     typedef int Type;
|>     Type        i;
|>     const Type  ci = 2;
|>     Type*       pi = &i;
|>     Type**      ppi = π

|>     const Type** ppci = ppi;            // error because
|>     *ppci = &ci;                        // now pi == &ci
|>     *pi = 0;                            // and now we modify ci

|>     const Type*const* pcpci = ppi;      // no problem because
|>     *pcpci = &ci;                       // this is impossible (since *pcpci is
|> const)
|> }

    char const    c( 'a' ) ;
    char const*    pc( &c ) ;
    char*        p ;
    char const**    ppc( &p ) ;    //  Currently illegal, since
                    //  &p has type char**, not
                    //  char const**.
    *ppc = pc ;
    *p = 'b' ;            //  Guess what is accessed.

Const is violated *without* ever being cast away.

|> Now a question:

|> Will there be any way to redefine (overload) normal && or || on class ?
|> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

|> I mean, now:

|> class Int {
|>     public:
|>         operator int () const { return i; }
|>         operator && (int) const;
|>         operator || (int) const;
|>         Int (int I) : i(I) { }

|>     private:
|>         int     i;
|> };

|> int     Func ()
|> {
|>     cout << "called\n";
|>     return 1;
|> }

|> void    foo ()
|> {
|>     int i (1);
|>     Int I (1);

|>     if (i || Func ()) // called is not printed
|>         ;
|>     if (I || Func ()) // called is printed
|>         ;
|> }

|> One could think that the standard should be change in order to support real
|> overloaded operator && and ||.

How?  Write a definition of how you think overloaded operator&& and ||
should work.

In the above case, IMHO, the correct solution is not to overload
operator||, but to define a conversion function for Int, e.g.:
Int::operator bool(), for example.
--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:[e-mail]
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:[e-mail]
]